EC2 中擴展與縮減的方法 - Day13

12th鐵人賽 auto scaling group cooldown period warm-up period health check grace period

yehchitsai

2020-09-13 16:06:57

2793 瀏覽

分享至

EC2 中擴展與縮減的方法 - Day13

今天要討論的是 Auto Scaling Up/Down 自動擴展或縮減 - Day12這樣的配置有何可以再改進的地方：
首先，根據 AWS 官方教材的作法，它們會建議把 Auto Scaling Group 放在私有子網，而 Elastic Load Balancing (ELB) 放在公有子網中。這樣的配置比較合理，因為這樣比較安全。

對於 Auto Scaling Group 的擴展與縮減政策需要做進一步的說明

擴展與縮減的方法

維持固定數量執行實例 Maintain current instance levels at all times

直接指定要執行的實例數量，簡單的做法就是在 Auto Scaling Group 中將所需容量 desired capacity/容量下線 minimum size/容量上限 maximum size 這三個值都設定一樣就可以。

圖一、Auto Scaling Group 維持固定數量執行實例

手動擴展 Manual scaling

手動將 EC2 實例附加到 Auto Scaling Group，到 EC2 主控台，選擇左邊選單中的 執行個體 Instances，按下右邊的建立啟動組態按鈕，當然也可以用相同操作將EC2 實例從 Auto Scaling Group 中移除。

圖二、將 EC2 實例附加到 Auto Scaling Group

排程擴展 Scale based on a schedule

排程擴展表示擴展動作將以時間和日期的函數的形式自動執行。當您確切知道何時要增加或減少群組中執行個體的數量時，這一點非常有用，這完全是因為需求是按照可預測的時程而產生的。
到 EC2 主控台，選擇左邊選單中的 Auto Scaling Groups，選擇指定的自動縮放群 ithomeASG ，按下下方的 自動調整規模(Automatic scaling) 頁簽，在這個頁簽會找到排定的動作欄，按下建立排定的動作，需入預定的時間以及需要的實例數量

圖三、在 Auto Scaling Group 中建立排定的動作

需求擴展 Scale based on demand

Amazon EC2 Auto Scaling 支援下列擴展政策類型：

目標跟蹤縮放政策 Target tracking scaling policies — 基於特定度量標準的目標值增加或減少組的當前容量，預設就是使用這個縮放政策。
步驟縮放政策 Step scaling policies — 基於一組擴展調整來增加或減少組的當前容量，稱爲步驟調整，根據警報觸發來調整縮放的大小。
簡單縮放政策 Simple scaling policies — 基於單個縮放調整增加或減少組的當前容量。

在詳細討論上述政策時我們先了解整個政策的制定過程，原則上所有政策應該都需要以下要件：

目標值：比方說CPU使用率達到50%以上、請求數達到10個以上等等。
動作：增加一個或是20%個實體、減少兩個實體。
觸動器：監控上述的目標值並通知這是一個 Auto Scaling Group 進行動作，這是由 CloudWatch 負責。

我們以下圖為例，這是一個 Auto Scaling Group 使用的是步驟縮放政策，一開始的所需容量: 10 個實例、最少：5 個實例、最多：20 個實例，而步進調整策略為：

添加 2 個實例，當（平均 CPU 利用率為 80-100% 時）
添加 1 個實例，當（平均 CPU 利用率為 60-80% 時）
刪除 1 個實例，當（平均 CPU 利用率為 20-40% 時）
刪除 2 個實例，當（平均 CPU 利用率為 0-20% 時）

當平均 CPU 利用率超過 60% 時，並沒有立即發出 CloudWatch Alerm ，這原因在於 CloudWatch 監控標準週期是 5 分鐘，如果希望有較小的監控週期，必須要調整為詳細監控，則為 1 分鐘檢查一次。從這可以發現，並非事件發生的同時就會立刻觸動指定的政策，監控時間間格設定越小，事件發生與觸動的時間差就會越小。

當添加 1 個實例的動作發生後，同時間就有 3 個計時器被觸發，分別是冷卻時間、暖機時間、運作狀態檢查寬限期計時器。接下來每一分鐘步進調整策略 1 都會被監控到，但會被忽略，因為還在冷卻時間內。當平均 CPU 利用率超過 80% 時，步進調整策略 2 被觸發了，對冷卻時間計時器而言，因為時間還沒到，所以它忽略這個動作、而暖機時間計時器則整合了剛剛第一個政策，因為已經有新增一個了，所以就再加一個實例就可以滿足步進調整策略 2 。

圖四、步驟縮放政策練習

冷卻時間 cooldown period: 是屬於 Auto Scaling Group，針對實例啟動或是終止都需套用這個時間，時間內忽略 CloudWatch 警告，對象是為 auto-scaling action，目的是以防止失控的擴展事件。如果系統的CPU使用率很高，並且您的自動縮放規則添加了一個實例，則將需要5分鐘左右的時間來完全啟動該實例並幫助減輕負載。如果沒有冷卻時間，該規則將繼續觸發，並可能在CPU指標下降之前添加4或5個實例，從而導致浪費的過度配置。或者在縮小的情況下，超調並導致配置不足。

運作狀態檢查寬限期 Health check grace period : 是屬於 Auto Scaling Group，針對實例啟動需套用這個時間，時間內忽略 CloudWatch 警告，對象是為實例。當 Amazon EC2 Auto Scaling 實例啓動時，等到 Health Check Grace Period 指定的時間到達才開始檢查實例的運行狀況。

暖機時間 Warm-up: 是屬於 scaling policies ，而只針對實例啟動時才需套用這個時間，時間內會整合 CloudWatch 警告，對象為 auto-scaling action。目的為設定實例和時加入或移除 Auto Scaling Group，執行向外擴展時，不會認為正在 warm-up 的執行個體是群組目前容量的一部分。執行向內擴展時，會認為正在中止的執行個體是群組目前容量的一部分。

AWS的定義

Cooldown period: the cooldown period helps to ensure that your Auto Scaling group doesn't launch or terminate additional instances before the previous scaling activity takes effect. You can configure the length of time based on your instance warmup period or other application needs. From AWS documentation
Health check grace period: frequently, an Auto Scaling instance that has just come into service needs to warm up before it can pass the health check. Amazon EC2 Auto Scaling waits until the health check grace period ends before checking the health status of the instance. From AWS documentation
Warm-up period : allows you to control the time until a newly launched instance can contribute to the CloudWatch metrics, so when warm-up time has expired, an instance is considered part Auto Scaling group and will receive traffic. From AWS documentation